1. Field of the Invention
This invention relates to mobile nodes or devices, and more specifically to efficient routing of packets of mobile nodes.
2. Background Information
Wireless access to the Internet is becoming more and more popular. Wireless devices used to access the Internet include, for example, mobile phones, personal digital assistants (PDA), and notebook computers. Mobile IP is an emerging set of extensions to the Internet Protocol (IP) for packet data transmission. This allows wireless devices (mobile nodes) to roam without continually changing the wireless device's IP addresses and reinitializing sessions.
The IP protocol routes packets to their destinations according to IP addresses. These addresses are normally associated with a fixed network location. When a packet origination or destination is a mobile node, each new point of attachment to the network made by a mobile node is associated with a new IP address. In mobile IP, when a mobile node moves to a village network (subnetwork outside of the mobile node's home subnetwork), the mobile node gets assigned a temporary address known as a Care of Address (CoA). The CoA changes at each new point of attachment by the mobile node. After a mobile node gets a CoA, the mobile node uses this care of address as the source IP address for its packets.
Many flows (i.e., set of packets with a common source address and destination address) only require a best effort class of quality of service (QoS). These type flows may not require strict bandwidth, delay, or other requirements. However, flows that carry IP packets comprising multimedia streams such as video conferencing may demand a higher level of quality of service. Therefore, it is important that mobile IP be interoperable with protocols that provide real time services in the Internet.
Resource reservation protocol (RSVP) is a protocol designed for an integrated services Internet. The RSVP protocol may be used by an originating node to request specific qualities of service from the network for particular application data streams or flows. RSVP may also be used by routers to deliver quality of service requests to all nodes along the paths of the flows and to establish and maintain state to provide the requested service. RSVP requests generally result in resources being reserved in each RVSP node (i.e., RSVP router) along the data path of the flow.
A RSVP reservation is based on a “flow spec” and a “filter spec”. The flow spec specifies a desired QoS, while the filter spec is used to set parameters in the packet classifier. In order to provide the appropriate desired QoS to a flow, a RSVP packet classifier selects data packets based on the filter spec which uses the sender IP address as one of the parameters and optionally the UDP/TCP port number.
When an RSVP node receives a flow containing one or more packets, the RSVP node tries to identify the packet based on the source (i.e., sender) IP address. For a mobile node that has moved from its home location, this source IP address will consist of the care of address in the IP header. When a channel is initially set up to carry a flow between a mobile node and a second node (e.g., correspondent node), the channel (i.e., path) is set up based on a home IP address of the mobile node, not the care of address. The home address tells RSVP routers that exist in the path, between the source and destination points of the flow, whether the packets get previously reserved resources associated with a flow from the home address. RSVP nodes only know home address and not care of address. Therefore, when an RSVP node processes packets as currently defined today, the original packet classifier does not recognize the flow from a relocated mobile node because the particular session (represented now by the care of address) will not match any of the filter specs (that contain the home address). Thus, the classifier cannot provide the desired QoS since routers on the path of the relevant traffic flows are not able to classify these packets correctly. The reserved resources will be wasted, and the flow will instead be handled as best effort traffic.
Moreover, using the current RSVP specification, a new end-to-end RSVP reservation procedure needs to be performed in order to maintain the same QoS after the mobile node has obtained a new care of address. This is not realistic and inefficient for real time applications because the traffic (flow) sent while the end-to-end reservation procedure takes place can only obtain best effort treatment. Current methods use the care of address for flow identification, however, the care of address can change rapidly during a flows lifetime, therefore, making this method also problematic.
Another problem arises when a mobile node changes its point of attachment and performs handoff. In the uplink direction, a mobile node can reissue a path message, which causes a RESV message to be sent from a crossover router (i.e., a router which lies in both the old and new path from a mobile node to a correspondent node). However, the reservation on the old path between the crossover router and the mobile node's former point of attachment remains in place until the reservation state for this path times out. This is problematic, especially when considering that a mobile node can change its point of attachment very frequently.
Another problem is that the old care of address of a mobile node may be reused after it changes its point of attachment to the Internet. This may imply that if reservations are identified based on the care of address, another node could benefit from a reservation which has not been removed and which has also not timed out yet.
A further problem with current systems is that if sessions are identified based on the care of address, it is necessary to set up fully new RSVP sessions after a mobile node receives a new care of address instead of just updating the existing sessions. In the worst case, this could mean that a session which still exists for a mobile node's old care of address (i.e., a session which has not timed out yet) could block the establishment of the session for the new care of address, even though both sessions are meant to handle the same traffic flow.
Moreover, a problem exists in that in order for RSVP daemon in a correspondent node to obtain the care of address of the mobile node, mobile IP needs to provide an interface to reveal the care of address of the mobile node, which could also be used by any other application. This violates the location privacy requirement.
A further problem exists in that it is also necessary to always negotiate the new RSVP sessions all the way between a mobile node and a correspondent node. This precludes optimized solutions where it would be possible to only set up the path between the mobile node and the crossover router.
In addition, current methods of handoffs when a mobile node moves to another point of attachment are inefficient. Currently, when a mobile node moves to another point of attachment, the mobile node sends a binding update to the correspondent node. However, the correspondent node does not act upon it immediately. Therefore, the path between the crossover router and the mobile node does not receive the proper QoS until the next PATH refresh message. Additionally, if a mobile node sends a RESV refresh message before the next PATH refresh message, the mobile node receives a error message because the routers on the path between the mobile node and crossover router are not aware of the RSVP session yet. An immediate solution to this problem may be to trigger a PATH refresh at the correspondent node when the binding update is received. However, this implies that it takes one and one half round trips between the mobile node and the correspondent node to set up the QoS on the path between the mobile node and crossover router (which may be a very short path as compared to the path between the mobile node and correspondent node). This mechanism is highly inefficient.
Therefore, there is a need for efficient routing of mobile node packets, specifically when RSVP is used in mobile IP nodes.